Information processing apparatus

ABSTRACT

Upon receipt of a service data request from a client, a license server offering a key to decrypt a content transmits a user information request to the client. On receiving the user information request, the client displays a message prompting its user to enter such user information as the user&#39;s personal information and accounting information. The user information thus entered is sent from the client to the license server. On receiving the user information, the license server assigns a leaf of a key-managed hierarchical tree structure to the client, generates a set of node keys as a device node key, sends to the client the device node key together with a leaf ID and a private key of the client in question, and records the user information in correspondence with the leaf ID.

TECHNICAL FIELD

The present invention relates to an information processing apparatus.More particularly, the invention relates to an information processingapparatus for managing the copyrights of contents without hampering thedistribution of such contents.

BACKGROUND ART

Conventionally, the copyrights of audio and video contents have beenmanaged primarily by limiting the extent of their copies. The emphasisis on preventing illegal copies of the contents offered.

However, measures to thwart illegal copies tend to restrict thedistribution itself of contents. This has made it difficult efficientlyto distribute large quantities of contents to large numbers of users.

DISCLOSURE OF INVENTION

The present invention has been made in view of the above circumstancesand provides an apparatus, a method, and a program for efficientlydistributing large quantities of contents while ensuring securemanagement of their copyrights.

In carrying out the invention and according to a first aspect thereof,there is provided an information processing apparatus comprising: areceiving element for receiving a key request from a second informationprocessing apparatus; a generating element for generating a device nodekey by assigning the second information processing apparatus to a leafof a key-managed hierarchical tree structure; and a transmitting elementfor transmitting to the second information processing apparatus thedevice node key generated by the generating element.

In a preferred structure according to the first aspect of the invention,the transmitting element may further transmit leaf identificationinformation for identifying the leaf assigned to the second informationprocessing apparatus.

In another preferred structure according to the first aspect of theinvention, the transmitting element may further transmit a private keyassigned to the second information processing apparatus.

In a further preferred structure according to the first aspect of theinvention, the information processing apparatus may further comprises astorage element for storing a use condition for each license.

In a further preferred structure according to the first aspect of theinvention, the receiving element may further receive user informationabout a user of the second information processing apparatus.

In an even further preferred structure according to the first aspect ofthe invention, the information processing apparatus may further comprisea recording element for recording user information received by thereceiving element, in correspondence with leaf identificationinformation for identifying the leaf assigned to the second informationprocessing apparatus.

According to a second aspect of the invention, there is provided aninformation processing method comprising the steps of: receiving a keyrequest from a second information processing apparatus; generating adevice node key by assigning the second information processing apparatusto a leaf of a key-managed hierarchical tree structure; and transmittingto the second information processing apparatus the device node keygenerated in the generating step.

According to a third aspect of the invention, there is provided astorage medium which stores a computer-readable program comprising thesteps of: receiving a key request from the second information processingapparatus; generating a device node key by assigning the secondinformation processing apparatus to a leaf of a key-managed hierarchicaltree structure; and transmitting to the second information processingapparatus the device node key generated in the generating step.

According to a fourth aspect of the invention, there is provided aprogram causing the computer to carry out the steps of: receiving a keyrequest from the second information processing apparatus; generating adevice node key by assigning the second information processing apparatusto a leaf of a key-managed hierarchical tree structure; and transmittingto the second information processing apparatus the device node keygenerated in the generating step.

Through the use of the inventive information processing apparatus,information processing method, and program outlined above, a key requestis first received from a second information processing apparatus. Adevice node key is then generated with the second information processingapparatus assigned to a leaf of a key-managed hierarchical treestructure. The device node key thus generated is transmitted to thesecond information processing apparatus.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram outlining a typical configuration of a contentproviding system according to the invention;

FIG. 2 is a block diagram showing a typical structure of a clientincluded in the system of FIG. 1;

FIG. 3 is a flowchart of steps constituting a content downloadingprocess performed by the client in FIG. 1;

FIG. 4 is a flowchart of steps constituting a content providing processperformed by a content server included in the system of FIG. 1;

FIG. 5 is a schematic view of a format applicable to step S26 in FIG. 4;

FIG. 6 is a flowchart of steps constituting a content reproducingprocess performed by the client in FIG. 1;

FIG. 7 is a flowchart of steps constituting a license acquiring processin step S43 of FIG. 6;

FIG. 8 is a schematic view of a license structure;

FIG. 9 is a flowchart of steps constituting a license providing processperformed by a license server included in the system of FIG. 1;

FIG. 10 is a flowchart of detailed steps constituting a license renewingprocess in step S45 of FIG. 6;

FIG. 11 is a flowchart of steps constituting a license renewing processperformed by the license server in FIG. 1;

FIG. 12 is an explanatory view of a key structure;

FIG. 13 is an explanatory view of a category node arrangement;

FIG. 14 is a schematic view illustrating typical correspondences betweennodes and devices;

FIG. 15A is an explanatory view of an enabling key block structure;

FIG. 15B is an explanatory view of another enabling key block structure;

FIG. 16 is an explanatory view showing how an enabling key block isutilized;

FIG. 17 is a schematic view indicating a typical format of the enablingkey block;

FIG. 18 is an explanatory view depicting a tag structure of the enablingkey block;

FIG. 19 is an explanatory view sketching a content decrypting processusing a device node key (DNK);

FIG. 20 is a schematic view of a typical enabling key block;

FIG. 21 is an explanatory view picturing how a plurality of contents areassigned to a single device;

FIG. 22 is an explanatory view of license categories;

FIG. 23 is a timing chart explaining how a registering process iscarried out;

FIG. 24 is a flowchart of steps constituting a ripping process performedby the client;

FIG. 25 is an explanatory view of a watermark structure;

FIG. 26 is a schematic view of a typical content format;

FIG. 27 is a schematic view of a typical public key certificate;

FIG. 28 is an explanatory view showing how a content is distributed;

FIG. 29 is a flowchart of steps constituting a content check-out processperformed by the client;

FIG. 30 is an explanatory view depicting how enabling key blocks aretraced by tag;

FIG. 31 is a schematic view of a typical enabling key block structure;

FIG. 32 is an explanatory view of a mark structure;

FIG. 33 is a flowchart of steps constituting a license purchasingprocess performed by the client;

FIG. 34 is a flowchart of steps constituting a license purchasingprocess performed by the license server;

FIG. 35 is a schematic view of a typical mark structure;

FIG. 36 is a flowchart of steps constituting a certificate registeringprocess performed by the client;

FIG. 37 is a flowchart of steps constituting a certificate registeringprocess performed by the content server;

FIG. 38 is a schematic view of typical group certificates;

FIG. 39 is a flowchart of steps constituting a process performed by thecontent server where grouping is in effect;

FIG. 40 is a schematic view of an encrypted content key;

FIG. 41 is a flowchart of steps constituting a process performed by aclient belonging to a group;

FIG. 42 is a flowchart of steps constituting a process performed by aclient checking out a license to another client;

FIG. 43 is a flowchart of steps constituting a process performed by aclient having a license checked out from another client;

FIG. 44 is a flowchart of steps constituting a reproducing processperformed by a client having a license checked out thereto;

FIG. 45 is a flowchart of steps constituting a process performed by aclient having a license checked in from another client;

FIG. 46 is a flowchart of steps constituting a process performed by aclient having a license checked in to another client;

FIG. 47 is an explanatory view showing how a message authentication code(MAC) is generated;

FIG. 48 is an explanatory view outlining a decrypting process of anintegrity check value (ICV) generation key;

FIG. 49 is an explanatory view illustrating another decrypting processof the ICV generation key;

FIG. 50A is an explanatory view depicting how a license copying processis managed with TCV;

FIG. 50B is another explanatory view indicating how the license copyingprocess is managed with ICV; and

FIG. 51 is an explanatory view showing how licenses are managed.

BEST MODE FOR CARRYING OUT THE INVENTION

FIG. 1 outlines a typical configuration of a content providing systemaccording to the invention. Clients 1-1 and 1-2 (simply called theclient 1 hereunder if there is no need for distinction therebetween) areconnected to the Internet 2. Although only two clients are shownconfigured in the example of FIG. 1, any number of clients may beconnected to the Internet 2 in practice.

The Internet 2 is also connected with a content server 3, a licenseserver 4, and an accounting server 5. The content server 3 providescontents to the client 1. The license server 4 offers the client 1licenses for using the contents provided by the content server 3. Theaccounting server 5 performs an accounting process regarding the client1 having acquired a license.

Any number of content servers 3, license servers 4, and accountingservers 5 may be configured and connected to the Internet 2 in practice.

FIG. 2 shows a typical structure of the client 1.

In FIG. 2, a CPU (central processing unit) 21 carries out variousprocesses using programs held in a ROM (read-only memory) 22 or thoseloaded from a storage unit 28 into a RAM (random access memory) 23. Atimer 20 keeps time and supplies time information to the CPU 21. Asneeded, the RAM 23 may accommodate data required by the CPU 21 inexecuting diverse processes.

An encryption/decryption unit 24 encrypts content data and decryptspreviously encrypted content data. A codec unit 25 encodes content dataillustratively according to ATRAC3 (Adaptive Transform Acoustic CodingVersion 3) standards, and sends the encoded data through an I/Ointerface 32 to a semiconductor memory 44 in a drive 30 for storage. Thecodec unit 25 also decodes encoded data retrieved from the semiconductormemory 44 in the drive 30.

The semiconductor memory 44 is illustratively constituted by a MemoryStick (trademark).

The CPU 21, ROM 22, RAM 23, encryption/decryption unit 24, and codecunit 25 are interconnected via a bus 31. The bus 31 is further connectedto the I/O interface 32.

The I/O interface 32 is connected with an input unit 26, an output unit27, a storage unit 28, and a communication unit 29. The input unit 26comprises a keyboard and a mouse. The output unit 27 is composed of adisplay such as a CRT or an LCD as well as speakers. The storage unit 28is typically made up of a hard disc drive. The communication unit 29 isillustratively composed of a modem or a terminal adapter that executescommunication processes over the Internet 2. The communication unit 29also exchanges analog or digital signals with other clients.

The I/O interface 23 is also connected to the drive 30 as needed. Thedrive 30 is loaded with a storage medium such as a magnetic disc 41, anoptical disc 42, a magneto-optical disc 43, or a semiconductor memory 44where necessary. Computer programs are retrieved from the loaded storagemedium and installed into the storage unit 28 as needed.

Although not shown, the content server 3, license server 4, andaccounting server 5 are each constituted by a computer having basicallythe same structure as that of the client 1 in FIG. 2. In the descriptionthat follows, structural details in FIG. 2 will be cited as applicableto the content server 3, license server 4, and accounting server 5 aswell.

How the client 1 is provided with a content from the content server 3will now be described by referring to the flowchart of FIG. 3.

The user orders access to the content server 3 by operating the inputunit 26. In response, the CPU 21 reaches step S1 and causes thecommunication unit 29 to access the content server 3 via the Internet 2.In step S2, the user inputs information for designating the content tobe provided by operating the input unit 26. Given thecontent-designating information, the CPU 21 reports the information tothe content server 3 through the communication unit 29 and via theInternet 2. Upon receipt of the report, the content server 3 returnsencrypted content data, as will be described later with reference to theflowchart of FIG. 4. In step S3, the CPU 21 receives the transmittedcontent data through the communication unit 29. In step S4, the CPU 21records the encrypted content data to the hard disc constituting thestorage unit 28.

Described below with reference to the flowchart of FIG. 4 is a contentproviding process carried out by the content server 3 in conjunctionwith the above-described process by the client 1. In the ensuingdescription, the structural details of the client 1 in FIG. 2 will becited as applicable to the content server 3 as well.

In step S21, the CPU 21 of the content server 3 waits until it isaccessed by the client 1 through the communication unit 29 and over theInternet 2. When accessed by the client 1, the CPU 21 reaches step S22and acquires content-designating information sent from the client 1.This is the information reported by the client 1 in step S2 of FIG. 3.

In step S23, the CPU 21 of the content server 3 retrieves from thestorage unit 28 the content designated by the information acquired instep S22. In step S24, the CPU 21 supplies the encryption/decryptionunit 24 with the content data retrieved from the storage unit 28 andcauses the unit 24 to encrypt the supplied data using a content key Kc.

All content data held in the storage unit 28 have already been encodedby the codec unit 25 based on ATRAC3. Any encoded content data retrievedfrom the storage unit 28 are thus encrypted further by theencryption/decryption unit 24.

Obviously, all content data to be placed in the storage unit 28 may beencrypted in advance. In such a case, step S24 of FIG. 4 may be skipped.

In step S25, the CPU 21 of the content server 3 adds key information(i.e., enabling key block (EKB) and data K_(EKBC)(Kc) to be describedlater by referring to FIG. 5) needed to decrypt the encrypted content,and a license ID for identifying the license granting the use of thecontent, to a header as part of a format in which to transmit theencrypted content data. In step S26, the CPU 21 of the content server 3transmits the content encrypted in step S24 and the header furnishedwith the key and license ID in step S25 to the accessing client 1through the communication unit 29 and over the Internet 2.

FIG. 5 shows a typical format in which the content server 3 providescontent data to the client 1. As illustrated in FIG. 5, the format ismade up of a header and a data part.

The header comprises content information, a URL (uniform resourcelocator), a license ID, an enabling key block (EKB), and dataK_(EKBC)(Kc) as the content key Kc encrypted by use of a key K_(EKBC)derived from the EKB. The EKB will be described later in more detailwith reference to FIGS. 15A and 15B.

The content information includes a content ID (CID) as information foridentifying the content data formatted as data, and a codec method forcoding and decoding the content in question.

The URL is information denoting the address to be accessed in acquiringthe license designated by the license ID. Illustratively with the systemof FIG. 1, the URL stands for the address of the license server 4 fromwhich to acquire licenses. The license ID identifies the license to beneeded in utilizing the relevant content recorded as data.

The data part comprises any number of encryption blocks. Each encryptionblock is made up of an initial vector (IV), a seed, and data EK′c(data)obtained by encrypting the content data using a key K′c.

The key K′s is constituted by a value obtained by applying the contentkey Kc and a randomly established seed (value) to a hash function, asdefined by the following expression:K′c=Hash(Kc,Seed)

Each encryption block is furnished with a different initial vector (IV)and a different seed.

The encryption of content data is carried out in units of eight bytes.Each eight-byte portion is encrypted by use of the encrypted result fromthe preceding eight-byte portion in what is known as CBC (cipher blockchaining) mode.

In CBC mode, the first eight-byte content data portion cannot beencrypted using the encrypted result from the preceding eight-byteportion. Instead, the first eight-byte portion is encrypted by use ofthe initial vector IV as the initial value.

With CBC mode in effect, even if any one encryption block is unlawfullydecrypted, the other encryption blocks will not be decryptedcorrespondingly.

This encryption scheme will be described later in more detail byreferring to FIG. 47.

This encryption scheme, it should be noted, is not limitative of theinvention. Alternatively, the content data may be encrypted by simplyutilizing the content key Kc.

In the manner described, the client 1 can acquire content dataunrestrainedly and free of charge from the content server 3. That is,large quantities of contents can be distributed in a fairlyunconstrained manner.

However, before using any acquired content, each client 1 must be inpossession of a license corresponding to the content. How the clientreproduces a content will now be described by referring to FIG. 6.

In step S41, the CPU 21 of the client 1 acquires content ID information(CID) designated by the user operating the input unit 26. The IDinformation may be constituted illustratively by a content title and anumber unique to each of the stored contents.

When a given content is designated, the CPU 21 reads a license IDrelative to the content (i.e., ID of the license for granting the use ofthe content). The license ID is described in the header of the encryptedcontent data, as depicted in FIG. 5.

In step S42, the CPU 21 determines whether or not the licensecorresponding to the license ID retrieved in step S41 has already beenacquired by the client 1 and stored in the storage unit 28. If thelicense has yet to be acquired, the CPU 21 goes to step S43 and performsa license acquiring process. Details of the license acquiring processwill be described later with reference to the flowchart of FIG. 7.

If in step S42 the license is judged to have been acquired already or ifthe license acquiring process is carried out in step S43, then step S44is reached. In step S44, the CPU 21 judges whether or not the acquiredlicense falls within the corresponding expiration date. Whether or notthe license has expired is determined by comparing the expiration datestipulated in the license (which will be described later by referring toFIG. 8) with the current date and time kept by the timer 20. If thelicense is judged to have expired, the CPU 21 goes to step S45 andperforms a license renewing process. Details of the license renewingprocess will be described later by referring to the flowchart of FIG.10.

If in step S44 the license is judged to be effective or if the licenseis renewed in step S45, then step S46 is reached. In step S46, the CPU21 reads the applicable encrypted content data from the storage unit 28and places the retrieved data into the RAM 23. In step S47, the CPU 21supplies the encryption/decryption unit 24 with the content data storedin the RAM 23 in units of encryption blocks as shown in FIG. 5, andcauses the unit 24 to decrypt the data using the content key Kc.

The content key Kc is obtained (to be described later in more detail byreferring to FIGS. 15A and 15B) illustratively as follows: a keyK_(EKBC) is first acquired using a device node key (DNK). The contentkey Kc is then obtained from the data K_(EKBC)(KC) (see FIG. 5) by useof the acquired key K_(EKBC).

In step S48, the CPU 21 supplies the codec unit 25 with the content datadecrypted by the encryption/decryption unit 24, and causes the codecunit 25 to decode the supplied data. The CPU 21 then sends the datadecoded by the codec unit 25 to the output unit 27 through the I/Ointerface 32. In turn, the output unit 27 converts the received digitaldata to analog format for audio output through the speakers.

How the license acquiring process is performed in step S43 of FIG. 6will now be described in detail with reference to the flowchart of FIG.7.

The client 1 accesses the license server 4 in advance for a registeringprocess whereby service data are acquired, including a leaf ID, a DNK(device node key), a private key paired with a public key for the client1, a public key of the license server 4, and certificates of therespective public keys. The registering process by the client 1 will bedescribed later in detail by referring to FIG. 23.

The leaf ID represents identification information assigned to eachclient. The device node key (DNK) is required in decrypting an encryptedcontent key Kc included in the enabling key block (EKB) corresponding tothe license of interest (DNK will be described later by referring toFIG. 12).

In step S61 of FIG. 7, the CPU 21 acquires from the header (FIG. 5) theURL corresponding to the license ID identifying the desired license. Asdescribed above, the URL denotes the address to be accessed in obtainingthe license associated with the license ID also described in the header.In step S62, the CPU 21 accesses the URL obtained in step S61. Morespecifically, the CPU 21 gains access to the license server 4 throughthe communication unit 29 and over the Internet 2. At this point, thelicense server 4 requests the client 1 to input license-designatinginformation for designating the license to be purchased (i.e., licenseneeded for the use of the content), a user ID, and a password (see stepS102 in FIG. 9). The CPU 21 displays the request on the display of theoutput unit 27. Given the display, the user operates the input unit 26to enter the license-designating information, user ID, and password. Theuser ID and password have been acquired in advance by the user of theclient 1 having accessed the license server 4 over the Internet 2.

In step S63, the CPU 21 acquires the license-designating informationfrom the input unit 26. In step S64, the CPU 21 obtains the previouslyacquired user ID and password. In step S65, the CPU 21 causes thecommunication unit 29 to transmit to the license server 4 over theInternet a license request comprising the entered user ID, password,license-designating information, and a leaf ID contained in the servicedata (to be described later).

In turn, as will be described later with reference to FIG. 9, thelicense server 4 either transmits the license based on the user ID,password, and license-designating information (in step S109), or doesnot transmit the license if relevant conditions are not met (in stepS112).

In step S66, the CPU 21 judges whether or not the license has arrivedfrom the license server 4. If the license is judged transmitted, stepS67 is reached in which the license is fed to the storage unit 28 forstorage therein.

If in step S66 the license is not judged transmitted from the licenseserver 4, then the CPU 21 goes to step S68 for error handling. Morespecifically, the CPU 21 inhibits any content reproducing processbecause the license for granting the use of the content in question isnot acquired.

It is only after the client 1 has obtained the license applicable to thelicense ID attached to the content data in carrying out the above steps,can the content be used for reproduction.

The license acquiring process of FIG. 7 may alternatively be carried outbefore each user proceeds to obtain any content.

The license offered to the client 1 contains use conditions, a leaf ID,and other data items as shown in FIG. 8.

The use conditions include such information as a use time limit withinwhich the content may be used, a download time limit within which thecontent may be downloaded, a maximum number of times the content may becopied, the number of times the content has been checked out so far, amaximum number of times the content may be checked out, the right torecord the content to a CD-R, a maximum number of copies that can bemade of the content to PDs (portable devices), the right to purchase thelicense outright, and the duty to keep use logs, all according to thelicense in question.

Described below with reference to the flowchart of FIG. 9 is how thelicense server 4 performs a license providing process in conjunctionwith the license acquiring process carried out by the client 1 in FIG.7. In this case, too, structural details in FIG. 2 will be cited asapplicable to the license server 4 as well.

In step S101, the CPU 21 of the license server 4 waits until it isaccessed by the client 1. The CPU 21 goes to step S102 when accessed bythe client 1. In step S102, the CPU 21 requests the accessing client 1to transmit a user ID, a password, and license-designating information.As described above, the user ID, password, leaf ID, andlicense-designating information (i.e., license ID) are transmitted fromthe client 1 in step S65 of FIG. 7. In turn, the CPU 21 of the licenseserver 4 receives and acquires what has been transmitted through thecommunication unit 29.

In step S103, the CPU 21 of the license server 4 gains access to theaccounting server 5 through the communication unit 29 and requests theaccounting server 5 to perform a credit authorization process regardingthe user corresponding to the user ID and password. Given the creditauthorization request from the license server 4 over the Internet 2, theaccounting server 5 examines the payment history or other suitablerecords of the user defined by the user ID and password. A check is madeillustratively to see if the user in question has failed to pay theprice of any license in the past. If the user is not judged to have suchnonpayment records, the accounting server 5 transmits creditauthorization data; if the user is judged to have any nonpaymentrecords, the accounting server 5 transmits credit rejection data.

In step S104, the CPU 21 of the license server 4 determines whether ornot the accounting server 5 has returned the credit authorization datafor granting the license to the user. If the credit authorization dataare judged returned, step S105 is reached. In step S105, the CPU 21retrieves from the storage unit 28 one of the stored licenses whichcorresponds to the license-designating information acquired in stepS102. Each license held in the storage unit 28 has a license ID, versioninformation, a date and time of preparation, and an expiration datedescribed therein beforehand. In step S106, the CPU 21 adds the receivedleaf ID to the license. In step S107, the CPU 21 selects the useconditions corresponding to the license selected in step S105. If theuse conditions were designated in step S102 by the user, the designateduse conditions may be added as needed to the previously prepared useconditions. The CPU 21 furnishes the license with the use conditionsthus selected.

In step S108, the CPU 21 affixes a digital signature to the license byuse of a private key from the license server 4. This step generates alicense whose structure is shown in FIG. 8.

In step S109, the CPU 21 of the license server 4 transmits the license(shown structurally in FIG. 8) to the client 1 through the communicationunit 29 and over the Internet 2 In step S110, the CPU 21 of the licenseserver 4 places into the storage unit 28 the license that has just beentransmitted (including the use conditions and leaf ID) in correspondencewith the user ID and password acquired in step S102. In step S111, theCPU 21 carries out an accounting process. More specifically, through thecommunication unit 29, the CPU 21 requests the accounting server 5 tocarry out an accounting process regarding the user corresponding to theuser ID and password. Given the accounting request, the accountingserver 5 bills the user for the license. If the user fails to pay thebilled amount, the user from then on will be banned from acquiring anyfurther license that may be requested.

In such a case, the accounting server 5 returns in step S104 the creditrejection data banning the granting of the requested license. Step S104is then followed by step S112 in which the CPU 21 performs errorhandling. More specifically, the CPU 21 of the license server 4 outputsto the client 1 having gained access through the communication unit 29 amessage saying that the license cannot be granted to the user. The CPU21 then terminates the process.

In this case, the user cannot utilize the content (i.e., unable todecrypt the content), having failed to receive the license for thereason above.

FIG. 10 is a flowchart of detailed steps constituting a license renewingprocess in step S45 of FIG. 6. Steps S131 through S135 in FIG. 10 arebasically the same as steps S61 through S65 in FIG. 7, except that instep S133 the CPU 21 acquires the ID of the license that is not to bepurchased but to be renewed. In step S135, the CPU 21 transmits to thelicense server 4 the ID of the license to be renewed together with theuser ID and password.

In response to the transmission from the client 1 in step S135, thelicense server 4 proposes use conditions as will be described later (instep S153 of FIG. 11). In step S136, the CPU 21 of the client 1 receivesthe proposed use conditions from the license server 4 and forwards thereceived conditions to the output unit 27 for display. The user mayselect desired use conditions from those proposed or may add newconditions thereto by operating the input unit 26. In step S137, the CPU21 transmits to the license server 4 sign-up data for purchasing theselected use conditions (i.e., conditions for renewing the license)-.Upon receipt of the sign-up data, the license server 4 returnsdefinitively proposed use conditions (in step S154 of FIG. 11). In stepS138, the CPU 21 of the client 1 acquires the use conditions from thelicense server 4. In step S139, the CPU 21 substitutes the newlyacquired use conditions for the currently stored use conditionscorresponding to the license in the storage unit 28.

FIG. 11 is a flowchart of steps constituting a license renewing processperformed by the license server 4 in conjunction with the licenserenewing process carried out by the client 1 as described above.

In step S151, the CPU 21 of the license server 4 is first accessed bythe client 1. In step S152, the CPU 21 receives the license-designatinginformation transmitted by the client 1 in step S135 together with alicense renewal request.

In step S153, given the license renewal request, the CPU 21 retrievesfrom the storage unit 28 the use conditions (to be renewed)corresponding to the license in question. The retrieved use conditionsare transmitted to the client 1.

Upon receipt of the use conditions thus proposed, the client 1 signs upfor the purchase of the conditions in step S137 of FIG. 10 as describedabove. In step S154, the CPU 21 of the license server 4 generates datacorresponding to the use conditions that the client 1 has signed up topurchase, and transmits the generated data to the client 1. In turn, theclient 1 renews the use conditions of the currently registered licenseby utilizing the use conditions received in step S139 as describedabove.

The inventive system, as shown in FIG. 12, manages the keys of devicesand licenses based on the principle of what is known as broadcastencryption (refer to Japanese Patent Laid-open No. 2001-352321). Thekeys make up a hierarchical tree structure in which the leaves at thebottom level correspond to the keys of individual devices. In theexample of FIG. 12, keys are generated to represent 16 devices orlicenses numbered 0 through 15.

Each key is defined so as to correspond with each of the nodes (shown ascircles in the figure) constituting the tree structure. In this example,a root key KR denotes the root node at the highest level; keys K0 and K1correspond to the nodes at the second-highest level; keys K00 throughK11 represent the nodes at the third-highest level; and keys K000through K111 match the nodes at the fourth-highest level. Keys K0000through K1111 correspond to the leaves representative of the nodes atthe bottom level (i.e., device nodes).

In this hierarchical structure, the key immediately above, say, keysK0010 and K0011 is a key K001; and the key immediately above keys K000and K001 is a key K00. In like manner, keys K00 and K01 are topped by akey K0, and keys K0 and K01 are topped by the route key KR.

The key granting the use of any content is managed in the form of a keycorresponding to each node on a single path ranging from a given leaf atthe bottom level to the root node at the topmost level. For example, thekeys granting the use of a content based on the license relative to nodeNo. 3 (leaf ID) are managed in the form of a path comprising the keysK001, K001, K00, K0, and KR.

The inventive system, as shown in FIG. 13, manages the keys of devicesand licenses using a key system based on the principle depicted in FIG.12. In the example of FIG. 13, nodes at “8+24+32” levels constitute atree structure in which each of the nodes ranging from the route node tothe eighth-highest level is matched with a given category of devices.Illustratively, one category may comprise devices each employing aspecific semiconductor memory such as Memory Stick; another category mayinclude devices designed to receive digital broadcasts. To any one ofsuch category nodes applies this system (indicated as the T system inthe figure) acting as a license-managing system.

That is, licenses are made to correspond with the keys representing thenodes at the 24 levels below the node of this system (T system) In thiscase, it is possible to define as many as 2 to the 24th power (about 16million) licenses. If the lowest 32 levels are also taken into account,it is possible to define as many as 2 to the 32nd power (about 4billion) users (or clients). A device node key (bNK) refers to the keycorresponding to each of the nodes on a given path ranging from any oneof the leaves denoting the nodes at the lowest 32 levels to the rootnode. A leaf ID denotes the ID of any one of the leaves at the bottomlevel of the structure.

Each of the keys of devices and licenses corresponds to one of the pathsmade up of the nodes at the 64 (=8+24+32) levels. For example, a contentkey derived from a particular content through encryption is encrypted byuse of the keys corresponding to the nodes making up the path assignedto the license of interest. The key at a given level is encrypted usingthe keys at the immediately lower level before being placed into anenabling key block (EKB; to be discussed later by referring to FIGS. 15Aand 15B). The DNK is not placed within the EKB but is described in theservice data supplied to the client 1 of the user. Using the DNKcontained in the service data, the client 1 decrypts that key of theimmediately higher level which is described in the EKB (see FIGS. 15Aand 15B) distributed along with the content data. Using the key thusdecrypted, the client 1 decrypts that key at the next higher level whichis also described in the EKB. This decrypting process is repeated by theclient 1 so as to obtain all keys belonging to the path in question.

FIG. 14 shows a typical hierarchical tree structure for classifyingcategories. The highest level in the hierarchical tree structure of FIG.14 is a root key KR 2301 followed by node keys 2302 at intermediatelevels. Leaf keys 2303 are defined at the bottom level of the structure.Each device is assigned its own leaf key, a series of node keys rangingfrom the leaf key to the root key, and the root key.

The nodes at the M-th highest level (M=8 in the example of FIG. 13) aredefined as category nodes 2304. That is, each of the nodes at the M-thhighest level is regarded as a node in which to establish a device of aspecific category. Any one of the category nodes at the M-th highestlevel tops those nodes and leaves at the (M+1)th highest and subsequentlevels which are associated with devices subsumed in the category inquestion.

For example, a node 2305 at the M-th highest level in FIG. 14 is set forthe category called “Memory Stick (trademark).” All nodes and leavesunder this node are used exclusively to establish various devices eachutilizing Memory Stick. In other words, the nodes and leaves under thenode 2305 are defined as a set of nodes and leaves associated withdevices classified in the Memory Stick category.

Further a subcategory node 2306 may be established illustrativelyseveral levels below the M-th highest level. In the example of FIG. 14,a “reproduction-only device” node 2306 is shown established two levelsbelow the “Memory Stick” category node 2305 as a subcategory nodesubsumed in the category of the Memory Stick-using devices. Immediatelybelow the “reproduction-only device” subcategory node 2306 is a node2307 for establishing a telephone with music reproduction capability;the node 2307 is subsumed in the “reproduction-only device” subcategory.Immediately below the “telephone with music reproduction capability”category are a “PHS” node 2308 and a “mobile telephone” node 2309, bothsubsumed in the “telephone with music reproduction capability” category.

The categories and subcategories are not limited to the types of devicesalone; they may also be applied to nodes managed by manufacturers,content providers, banking or settlement organizations or the like intheir unique manner in the form of processing units, jurisdictionalunits, units of provided services, or any other suitable units (calledentities hereunder) For example, one category node may be established asthe highest-level node dedicated to a game console XYZ marketed by agame console manufacturer. In this case, the manufacturer can market thegame console XYZ by furnishing it with entities denoted by node keys orleaf keys that come under the topmost node. Thereafter, in distributingor renewing encrypted contents or various keys, the manufacturer maygenerate enabling key blocks (EKB) each constituted by any of the nodekeys or leaf keys under the highest-level node key in order todistribute data that can be used only on the devices corresponding tothe nodes or leaves involved.

As described, where one node tops the other nodes defined as categoriesor subcategories subsumed in the highest node, a manufacturer, a contentprovider or any other organization managing the tree structure made upof these nodes may generate uniquely defined enabling key blocks (EKB)each covering nodes leading up to the highest-level node and maydistribute the generated blocks to any devices belonging to thesubordinate nodes under the topmost node. In that setup, any key may berenewed in a manner totally independent of the devices belonging to anyother category except the topmost node.

For example, in the tree structure of FIG. 12, four devices 0, 1, 2 and3 contained in a group possess common keys K00, K0 and KR as their nodekeys. This shared node key structure may be utilized in providing acommon content key to the devices 0, 1, 2 and 3 only. If the shared nodekey K00 is established as a content key, only the devices 0, 1, 2 and 3may be assigned the common content key without being furnished with anynew key. As another example, suppose that a new content key Kcon isencrypted using the node key K00 to generate a value Enc(K00, Kcon)which is then distributed to the devices 0, 1, 2 and 3 over a network orby use of suitable storage media. In that case, solely the devices 0, 1,2 and 3 can acquire the content key Kcon by decrypting the encryptedvalue Enc(K00, Kcon) using the shared node key K00. The notation Enc(Ka,Kb) represent the data obtained by encrypting data Kb with data Ka.

Suppose that at a given point “t” the keys K0011, K001, K00, K0 and KRowned by the device 3 are found to be exposed by a hacker throughanalysis. In that case, the device 3 needs to be isolated from thesystem in order to protect data exchanged within the system (i.e., inthe group of devices 0, 1, 2 and 3) This requires replacing the nodekeys K001, K00, K0 and KR with new keys K(t)001, K(t)00, K(t)0 and K(t)Rrespectively and informing the devices 0, 1 and 2 of the renewed keys.The notation K(t)aaa indicates a renewed key of a generation “t” derivedfrom a key Kaaa.

How renewed keys are distributed will now be described. The key renewalprocess is carried out illustratively by furnishing the devices 0, 1 and2 with a table composed of block data called an enabling key block(EKB), shown in FIG. 15A, distributed over the network or by use ofsuitable storage media. Each enabling key block (EKB) is constituted byencryption keys that are used to distribute renewed keys to the devicescorresponding to the leaves (i.e., nodes at the bottom level) in thetree structure such as that in FIG. 12. The enabling key block (EKB) mayalso be called a key renewal block (KRB).

The enabling key block (EKB) shown in FIG. 15A constitutes block datahaving a data structure in which only the devices needing to have theirnode keys renewed are allowed to do so. The example of FIG. 15A is theblock data prepared in such a manner as to distribute renewed node keysof the generation “t” to the devices 0, 1 and 2 in the tree structure ofFIG. 12. As is evident in FIG. 12, the devices 0 and 1 need renewed nodekeys K(t)00, K(t)0 and K(t)R while the device 2 requires renewed nodekeys K(t)001, K(t)00, K(t)0 and K(t)R.

As indicated by the EKB in FIG. 15A, each EKB contains a plurality ofencryption keys. The encryption key in the bottom row of FIG. 15A isEnc(K0010, K(t)001) representative of the renewed node key K(t)001encrypted by use of the leaf key K0010 owned by the device 2. The device2 acquires the renewed node key K(t)001 by decrypting the encryption keyEnc(K0010, K(t)001) using its own leaf key K0010. The renewed node keyK(t)001 obtained through such decryption may then be used to decryptanother encryption key Enc(K(t)001, K(t)00) in the second row from thebottom of FIG. 15A; the decryption yields another renewed key K(t)00.

Likewise, another encryption key Enc(K(t)00, K(t)0) in the second rowfrom the top in FIG. 15A is decrypted to provide a renewed node keyK(t)0; the renewed node key K(t)0 is then used to decrypt anotherencryption key Enc(K(t)0, K(t)R) in the topmost row of FIG. 15A toproduce a renewed root key K(t)R.

Meanwhile, the node key K000 is not subject to renewal. What the nodes 0and 1 need as renewed node keys are the keys K(t)00, K(t)O and K(t)R.The nodes 0 and 1 acquire the renewed node key K(t)00 by decrypting theencryption key Enc(K000, K(t)00) in the third row from the top in FIG.15A using the node key K000 included in the device node keys. In likemanner, the encryption key Enc(K(t)00, K(t)0) in the second row from thetop in FIG. 15A is decrypted so as to provide the renewed node keyK(t)0; the encryption key Enc(K(t)0, K(t)R) in the top row of FIG. 15Ais decrypted in order to produce the renewed root key K(t)R. This is howthe devices 0, 1 and 2 can obtain the renewed key K(t)R.

In FIG. 15, each of the indexes in the left-hand side column stands foran absolute address of a node key or a leaf key used as the decryptionkey for decrypting the corresponding encryption key listed in theright-hand side column.

Suppose that renewal of the node keys K(t)0 and K(t)R at the upperlevels of the tree structure in FIG. 12 is not necessary and that onlythe node key K00 needs to be renewed. In that case, the enabling keyblock (EKB) of FIG. 15B may be used to distribute the renewed node keyK(t)00 to the devices 0, 1 and 2.

The EKB shown in FIG. 15B is effective where a renewed content key isdistributed so as to be shared within a specific group of devices. As anexample, suppose that the devices 0, 1, 2 and 3 forming a group enclosedby dotted lines in FIG. 12 utilize a particular storage medium and thatthey need a renewed common content key K(t) con. In that case, a renewednode key K(t)00 is first derived from the node key K00 shared by thedevices 0, 1, 2 and 3. The renewed node key K(t)00 is then used toencrypt the renewed content key K(t)con, generating data Enc(K(t)00,K(t) con). The encrypted data Enc(K(t)00, K(t)con) are distributed tothe relevant devices together with the EKB shown in FIG. 15B. Thisdistribution process ensures distribution of the data which can be usedonly by the devices involved and which cannot be decrypted by any devicein any other group, such as device 4.

Illustratively, the devices 0, 1 and 2 can obtain the content keyK(t)con in effect at time “t” by decrypting the encrypted data using thekey K(t)00 derived from the EKB.

FIG. 16 schematically shows an example in which the content key K(t)conin effect at time “t” is acquired. In this example, the renewed commoncontent key K(t)con is encrypted using the renewed node key K(t)00 toproduce encrypted data Enc(K(t)00, K(t)con). The encrypted data are senton a storage medium to the device 0 for processing along with the EKBshown in FIG. 15B. This is an example where EKB-based encrypted messagedata are employed as the content key K(t)con.

As shown in FIG. 16, the device 0 first generates the node key K(t)00through the EKB process described above using the EKB at time t storedin the storage medium and the node key K000 included in the DNKpreviously stored in the device itself. The device 0 then decrypts therenewed content key K(t)con using the renewed node key K(t)00 decrypted,encrypts the decrypted content key K(t)con using the leaf key K0000specific to the device, and stores the encrypted key.

FIG. 17 depicts a typical format of the enabling key block (EKB). In theformat of FIG. 17, a version 601 is an identifier indicating the versionof this enabling key block. The version 601 has two functions: toidentify the most recent EKB, and to specify correspondence with thecontent. A depth 602 indicates how deep the level of a destinationdevice for EKB distribution is in the hierarchical tree structure, thedevice receiving the distributed enabling key block (EKB). A datapointer 603 points to the position of a data part 606 in the EKB. A tagpointer 604 and a signature pointer 605 point to the positions of a tagpart 607 and a signature 608 respectively.

The data part 606 accommodates data prepared illustratively byencrypting the node keys to be renewed. For example, the data part 606may store encryption keys regarding the renewed node keys shown in FIG.16.

The tag part 607 comprises tags that indicate the positions of theencrypted node keys and leaf keys contained in the data part 606. Howthe tags are furnished will now be described by referring to FIG. 18.

FIG. 18 depicts how the enabling key block (EKB) explained above withreference to FIG. 15A is typically distributed as data. The data, shownin tabular form in FIG. 18, include a top node address indicative of thetop node included in the encryption keys. In this example, the top nodeaddress is KR because the renewed key K(t)R of the root key is included.Here, the data Enc(K(t)0, K(t)R) in the highest row of the tablecorrespond to a position P0 in the hierarchical tree structure of FIG.18. The data Enc(K(t)00, K(t)0) in the next-highest row of the tablecorrespond to a position P00 at the lower left of the preceding dataposition in the tree structure. If data are present below a givenposition in the tree structure, the tag for that position is set to 0;if data are absent, the tag for the position is set to 1. The tag formatis given as {left (L) tag, right (R) tag}. In the position P00 at thelower left of the position P0 corresponding to the highest-row dataEnc(K(t)0, K(t)R) in the table of FIG. 18, data exist and thus the lefttag is set to 0 for the position P0. On the other hand, data are absentat the lower right of the position P0 so that the right tag is set to 1for that position. In this manner, all data are furnished with tags andare arranged in tabular form as shown in FIG. 18, with the data in rowsand the tags in columns.

Tags are established to indicate where a given data item Enc(Kxxx, Kyyy)is positioned in the tree structure. Whereas key data Enc(Kxxx, Kyyy), .. . held in the data part 606 are merely a series of encrypted data, thepositions of the encryption keys representing the data can be determinedin the tree structure through the use of the above-described tags. Ifthe tags were not used, the data could still be structured as

-   -   0: Enc(K(t)0, K(t)R)    -   00: Enc(K(t)00, K(t)0)    -   000: Enc(K((t)000, K(t)00)    -   . . .        using the node indexes relative to the encrypted data as        explained above with reference to FIGS. 15A and 15B. However,        such an index-based data structure spawns huge quantities of        redundant data, which can be detrimental to efficient data        distribution over the network. By contrast, where tags are used        as index data indicating where the keys are positioned, the key        positions can be determined with a significantly reduced amount        of data.

Returning to FIG. 17, the EKB format will be further explained. Asignature 608 denotes a digital signature affixed illustratively by akey management center (i.e., license server 4), a content provider(content server 3) or a banking or settlement organization (accountingserver 5) having issued the enabling key block (EKB). The device thathas received the EKB authenticates the signature to ascertain that theEKB has been issued by a legitimate EKB-issuing party.

FIG. 19 summarizes the process in which a content supplied by thecontent server 3 is used on the basis of the relevant license acquiredfrom the license server 4.

As illustrated, the content is first provided from the content server 3to the client 1 The client 1 is then furnished with the license from thelicense server 4. The content is encrypted (Enc(Kc, Content)) using acontent key Kc. The content key Kc is encrypted (Enc (KR, Kc)) using theroot key KR (obtained from the EKB and corresponding to the key K_(EKBC)in FIG. 5). The encrypted content key together with the EKB is added tothe encrypted content that is offered to the client 1.

The EKB in FIG. 19 contains the root key KR that can be decrypted usinga DNK (device node key) as shown in FIG. 20. The client 1 can thusobtain the root key KR from the EKB using the DNK contained in theservice data. The content key Kc is decrypted from the encrypted contentkey Enc (KR, Kc) by use of the root key KR. The content key Kc is thenused to decrypt the content from the encrypted data Enc(Kc, Content).

As described, where the DNK is assigned individually to each client 1,the license of a given client 1 can be revoked independently on thebasis of the principle described above with reference to FIGS. 12, 15Aand 15B.

When each license is distributed together with a leaf ID to the client1, the client 1 brings the service data into correspondence with thelicense. Such correspondence helps prevent illegal copying of thelicense.

Where a client-addressed certificate and a private key are distributedas the service data to each client, the end user at the client canprepare a content that is resistant to illegal copying through the useof the service data.

How the certificate and private key are utilized will be described laterwith reference to the flowchart of FIG. 29.

As described above with reference to FIG. 13, a given category node maybe established to bring the inventive content distribution system formanaging licenses into correspondence with a category of devices thatutilize diverse contents. That means the same device may be assigned aplurality of DNKs. It follows that contents of different categories canbe managed by a single device.

FIG. 21 shows how such content management is carried out. In the setupof FIG. 21, a device D1 retains service data and a license for using acontent 1 that is assigned DNK1 according to the inventive principle ofthe content distribution system. At the same time, the device D1 mayalso have a content 2 placed in a Memory Stick after it is ripped from aCD, the content 2 being assigned DNK2. In this case, the device D1 canconcurrently deal with different contents, that is content 1 and content2, distributed according to different systems (i.e., the contentdistribution system and the device management system) The arrangementabove is not adopted if the currently assigned DNK is deleted before anew DNK is assigned so that the device in question is always associatedwith a single DNK.

In the tree structure of FIG. 13, each of the triangles at the lowest 32levels may illustratively be assigned a license category 1 and a licensecategory 2 shown in FIG. 22. This means that any single category may bedivided into subcategories for better management covering detailed dataitems such as the genre of the content, the disc label involved, thedistributor's name, the type of distribution service, the source of thecontent, and a specific manner in which the content is offered.

In the example of FIG. 22, a license category 1 is shown covering thegenre of jazz and a license category 2 the genre of rock and roll. Thelicense category 1 is matched with contents 1 and 2 which have a licenseID of 1 each and which are distributed to users 1, 2 and 3. The licensecategory 2 comprises contents 3, 4 and 5 which having a license ID of 2each and which are provided to the users 1 and 3.

In this setup, keys can be managed independently in units of categoriesaccording to the invention.

Also according to the invention, it is possible to have DNKs downloadedthrough the license server 4 to individual devices or storage media atthe time of a registering process, instead of having the DNKsincorporated in devices or embedded on storage media beforehand. Thismakes it possible to implement a system for allowing users to acquirekeys.

How the above-mentioned registering process is performed by the client 1will now be described with reference to FIG. 23.

In step S161, the CPU 21 of the client 1 causes the communication unit29 to transmit a service data request to the license server 4. In stepS165, the CPU 21 of the license server 4 receives the service datarequest through the communication unit 29. In step S166, the CPU 21 ofthe license server 4 transmits a user information request to the client1 through the communication unit 29.

In step S162, the CPU 21 of the client 1 receives the user informationrequest through the communication unit 29. In turn, the CPU 21 causesthe output unit 27 to display a message prompting the user to enter userinformation. Upon viewing the message, the user operates the keyboard orthe like to enter the user information such as the user's personalinformation and accounting information into the input unit 26. In stepS163, the CPU 21 of the client 1 transmits the user-input information tothe license server 4 through the communication unit 29.

In step S167, the CPU 21 of the license server 4 receives the userinformation through the communication unit 29. In step S168, the CPU 21assigns the client 1 to any one of the unassigned leaves below the nodeof the category corresponding to the license server 4, and generates adevice node key in the form of a set of node keys assigned to the nodesalong the path ranging from the leaf assigned to the client 1 to thenode corresponding to the category of the license server 4. The CPU 21then generates service data by putting together the device node keygenerated as described, the leaf ID of the leaf assigned to the client1, a private key of the client 1, a public key paired with the privatekey of the client 1, a public key of the license server, andcertificates of the public keys. In step S169, the CPU 21 of the licenseserver 4 transmits the generated service data to the client 1 throughthe communication unit 29 and causes the drive 30 to record the userinformation to an appropriate storage medium such as a hard disc incorrespondence with the leaf ID.

In step S164, the CPU 21 of the client 1 receives the service datathrough the communication unit 29. In turn, the CPU 21 causes theencryption/decryption unit 24 to encrypt the received service data andcauses the drive 30 to write the encrypted data to a suitable storagemedium such as the hard disc.

In the manner described, the license server 4 registers the client 1 andits user. With the registration completed, the client 1 can receiveservice data including the device node key necessary for utilizing adesired content distribution service.

It is preferred that a content, once prepared, be made usable in anyapplications regardless of the way it is used. Illustratively, the samecontent should preferably be used in different content distributionservices or irrespective of the domain use status differing from onesituation to another. According to this invention, the license server 4acting as a certificate authority provides each user (i.e., client 1)with a private key and a certificate of a public key corresponding tothe private key. Each user prepares a signature using the distributedprivate key and affixes the signature to the content to attest itsintegrity, whereby any tampering of the content is prevented.

How the above process is carried out will now be described by referringto the flowchart of FIG. 24. The process of FIG. 24 constitutes aripping process performed by the user who reproduces data from a CD andstores the reproduced data into the storage unit 28.

In step S171, the CPU 21 of the client 1 first acquires data reproducedfrom the CD as write data through the communication unit 29. In stepS172, the CPU 21 determines whether or not the write data acquired instep S171 contain a watermark. The watermark, made up of three-bit copycontrol information (CCI) and one-bit trigger data, is embedded in thecontent data. If the watermark is detected, the CPU 21 goes to step S173to extract the watermark from the content. If no watermark is detected,step S173 is skipped.

In step S174, the CPU 21 prepares header data to be recorded incorrespondence with the content. The header data is composed of acontent ID, a license ID, the URL of the location to be accessed foracquisition of the license, and copy control information (CCI) alongwith trigger data included in the watermark.

In step S175, the CPU 21, using the client's private key, prepares adigital signature based on the header data generated in step S174. Theprivate key has been acquired earlier from the license server 4 (in stepS67 of FIG. 7).

In step S176, the CPU 21 causes the encryption/decryption unit 24 toencrypt the content using a content key. The content key is generatedillustratively through random number generation.

In step S177, the CPU 21 writes the data illustratively to themagneto-optical disc 43 such as a Mini-disc in accordance with asuitable file format.

Where the storage medium is a Mini-disc, the CPU 21 in step S176 feedsthe content to the codec unit 25 to encode the content based on ATRAC3.The encoded data are further encrypted by the encryption/decryption unit24.

FIG. 25 schematically shows how a content is written to a storage mediumin the manner described above.

A watermark (WM) is extracted from an encrypted content E(At3) andwritten outside the content (i.e., in the header).

FIG. 26 illustrates a more detailed file format in which to record thecontent to the storage medium. In the format of FIG. 26, a header madeup of a content ID (CID) a license ID (LID), a URL, and a watermark (WM)is recorded together with an EKB, data Enc(KR, Kc) prepared byencrypting a content key Kc using a root key KR, a certificate(Cert), adigital signature Sig(Header) derived from the header, data Enc(Kc,Content) generated by encrypting the content using the content key Kc,meta data, and a mark.

The watermark, usually embedded in the content, may be taken out of thecontent and placed into the header as shown in FIGS. 25 and 26. Such anoutside-content watermark arrangement permits easy and quick detectionof the information embedded in the content as the watermark, so that acheck can be made rapidly to determine whether or not the content inquestion is allowed to be copied.

The meta data represent such data as a jacket, photos, and lyricsregarding the content. The meta data will be described later in moredetail with reference to FIG. 32.

FIG. 27 schematically shows a typical public key certificate. The publickey certificate is usually issued by the certificate authority (CA) of apublic key cryptosystem. Illustratively, in order to prepare a publickey certificate, the certificate authority supplements the user ID andpublic key submitted by the user with an expiration date and otherinformation as well as a digital signature affixed by the authority.According to this invention, the license server 4 (or the content server3) issues a certificate and a private key (thus a public key as well) tothe user. In turn, the user submits his or her user ID and password tothe license server 4 for registration, whereby the public keycertificate is acquired.

The public key certificate in FIG. 27 has a message including a versionnumber of the certificate, a certificate serial number assigned by thelicense server 4 to the certificate user, an algorithm and parametersused for a digital signature, the name of the certificate authority(license server 4), an expiration date of the certificate, the ID of thecertificate user (node ID or leaf ID), and a public key of thecertificate user. The message is supplemented with the digital signatureprepared by the license server 4 acting as the certificate authority.The digital signature is made of data generated by use of the privatekey of the license server 4 on the basis of a hash value generated byapplying a hash function to the message.

In the example of FIG. 12, the device 0 is assigned a node ID or a leadID of “0000”; the device 1, the ID of “0001”; and the device 15, the IDof “1111.” Such IDs determine where each device (i.e., entity) ispositioned (as a leaf or a node) in the tree structure.

Where the license for granting the use of each content is distributedindependent of the content in question, the content can be distributedunrestrainedly. All contents acquired in any manner or through anychannels may then be handled in unified fashion.

If the file format is constituted as shown in FIG. 26, the copyright ofeach content in that format can be properly controlled not only when thecontent is distributed over the Internet but also when the content isoffered to SDMI (Secure Digital Music Initiative) apparatuses.

Furthermore, if the content is distributed on a storage medium or overthe Internet 2 as shown in FIG. 28, the content can be checked out to aportable device (PD) as an SDMI apparatus by resorting to the processexplained above.

Described below with reference to the flowchart of FIG. 29 is how theclient 1 checks out a content to another client (e.g., PD).

In step S191, the CPU 21 judges whether or not a digital signature isaffixed to the content. If the digital signal is judged affixed, stepS192 is reached. In step S192, the CPU 21 extracts a certificate fromthe content and authenticates it using a public key of the certificateauthority (i.e., license server 4). More specifically, the client 1acquires from the license server 4 a public key paired with the privatekey of the license server 4 and decrypts the digital signature affixedto the public key certificate by use of the acquired public key. Asdescribed above with reference to FIG. 27, the digital signature isprepared based on the private key of the certificate authority (licenseserver 4) and thus can be decrypted using the public key of the licenseserver 4. The CPU 21 further computes a hash value by applying a hashfunction to the whole message in the certificate. The CPU 21 comparesthe computed hash value with a hash value obtained by decrypting thedigital signature. If the two values match, the message is judged to befree of tampering. If the two hash values differ upon comparison, thecertificate is judged to have been tampered with.

In step S193, the CPU 21 checks to see whether or not the certificatehas been tampered with. If the certificate is judged to be free oftampering, step S194 is reached in which the certificate isauthenticated using the EKB. The authenticating process is carried outby determining whether or not it is possible to effect trace through theEKB based on the leaf ID included in the certificate (FIG. 27). How theauthenticating process is performed will now be described with referenceto FIGS. 30 and 31.

Suppose now that a device having a leaf key K1001 is a revoked device asshown in FIG. 30. In that case, an EKB having data (encryption keys) andtags shown in FIG. 31 is distributed to each device (leaf). The EKB isarranged so as to renew keys KR, K1, K10 and K100 for revoking thedevice 1001 in FIG. 30.

All leaves except the revoked device 1001 can acquire a renewed root keyK(t)R. That is, since the leaves below a node key KO each retain theunrenewed node key KO within the device, each of these leaves can obtaina renewed root key K(t)R by decrypting an encryption key Enc(K0, K(t)R)using the key K0.

The leaves below a node 11 may each acquire a renewed node key K(t)1 bydecrypting an encryption key Enc(K11, K(t)1) using a node key K11 yet tobe renewed. Furthermore, an updated root key K(t)R may be obtained bydecrypting an encryption key Enc(K(t)1, K(t)R) using the node key K(t)1.The leaves below a node key K101 may likewise obtain the renewed rootkey K(t)R.

A device 1000 having an unrevoked leaf key K1000 may acquire a node keyK(t)100 by decrypting an encryption key Enc(K1000, K(t)100) using itsown leaf key K1000. The node key K(t) 100 thus acquired is then usedsuccessively to decrypt node keys at higher levels until the renewedroot key K(t)R is obtained.

On the other hand, the revoked device 1001 is incapable of acquiring therenewed node key K(t)100 one level higher through the EKB process. Thatmeans the renewed root key K(t)R cannot be obtained.

The valid (i.e., unrevoked) device (client 1) is furnished with the EKBcontaining the data and tags shown in FIG. 31. The EKB is distributed bythe license server 4 to each device for storage therein.

Each client may carry out an EKB tracing process using the furnishedtags. The process involves determining whether or not the keydistribution tree may be traced starting from the topmost root key.

Illustratively, the leaf ID “1001” of the leaf 1001 in FIG. 30 may beregarded as four-bit data (1, 0, 0, 1). A check is then made to see ifthe tree structure can be traced starting from the most significant bit.A “1” bit is interpreted to indicate a rightward advance and a “0” bit aleftward advance.

Because the most significant bit of the ID “1001” is “1,” the traceadvances right from the root key KR in FIG. 30. The first tag (numbered0) in the EKB is defined as 0: {0, 0}, interpreted to indicate thepresence of data on both branches. Since the rightward advance is ineffect in this case, the node key K1 is reached.

The trace now goes to a node below the node key K1. The second bit inthe ID “1001” is 0, indicating a leftward advance. The tag numbered 1denotes the presence or absence of data below the node key K0 to theleft, and the tag numbered 2 represents the presence or absence of databelow the node key K1. The latter tag is formulated as 2: {0, 0} asshown in FIG. 31, interpreted to indicate the presence of data on bothbranches. In this case the advance is in the leftward direction, and thenode key K10 is reached.

The third bit in the ID “1001” is 0 denoting a leftward advance. The tagnumbered 3 indicates the presence or absence of data below the node keyK10. Formulated as 3: {0, 0}, this tag indicates the presence of data onboth branches. The advance is to the left and the node key K100 isreached.

The least significant bit in the ID “1001” is “1” indicative of arightward advance. The tag numbered 4 corresponds to the node key K11,and the tag numbered 5 denotes the sign of data under the node key K100.The latter tag is defined as 5: {0, 1} interpreted to indicate theabsence of data to the right. That means the node 1001 cannot bereached. As a result, the device with the ID “1001” is judged as arevoked device, i.e., a device that is banned from acquiring any renewedroot key through the EKB.

Meanwhile, a device with, say, the leaf key K1000 has the device ID of“1000.” When the EKG tracing process is carried out using the tags inthe EKB as described above, the node “1000” can be reached. This allowsthe device with the ID “1000” to be judged as a valid device.

Returning to FIG. 29, the CPU 21 in step S195 determines whether or notthe certificate has been revoked based on the result of theauthenticating process in step S194. If the certificate is not judged tobe revoked, step S196 is reached. In step S196, the digital signature isauthenticated using the public key contained in the certificate.

As shown in FIG. 27, the certificate contains the public key of thecertificate user (i.e., content provider). This public key is utilizedin authenticating the signature (in the header) shown in FIG. 26. Morespecifically, the public key is used to decrypt the digital signatureSig(Header) so as to obtain data (i.e., a hash value) for comparisonwith a hash value computed by applying a hash function to the header inFIG. 26. If the two hash values match, it means the header has not beentampered with. If the two hash values differ, that means the header hasbeen tampered with.

In step S197, the CPU 21 determines whether or not the header has beentampered with. If no tampering is detected, step S198 is reached inwhich the watermark is authenticated. In step S199, the CPU 21determines whether or not the result of watermark authenticationjustifies a check-out process. If the check-out process is judged to beallowed, then step S200 is reached in which the CPU 21 checks out thecontent. Specifically, the CPU 21 transfers the content to the client 1of the check-out destination for copying.

Step S201 is reached for error handling and check-out is inhibited inany one of the following cases: if no digital signature is judged toexist in step S191; if the certificate is judged to have been tamperedwith in step S193; if the certificate cannot be authenticated in stepS195 based on the EKB; if the result of digital signature authenticationin step S197 has revealed that the header has been tampered with; or ifthe watermark is interpreted to require suppression of check-out in stepS199.

As described, the license server 4 distributes a certificate and aprivate key to each user. Upon preparing a content, the user affixes adigital signature to the content to attest its integrity, wherebyillegal distribution of the content is inhibited.

The watermark is extracted during preparation of the content and thewatermark information is added to the digital signature. This protectsthe watermark information against tampering and ensures the integrity ofthe content.

Each content, once prepared, is thus ensured in its integrity regardlessof the manner in which the content is distributed.

Since the use conditions are attached not to each content but to thelicense for granting the use of that content, the use conditions for allcontents associated with a given license may be changed collectively asneeded by simply changing the use conditions of the license in question.

How a mark is used will now be explained. As described above, useconditions are added not to contents but to licenses. It might happenthat contents relative to a given license are subject to individuallydifferent usages. This state of affairs is dealt with by adding marks tothe contents under a given license according to the invention.

Because one license is matched with a plurality of contents, it isdifficult to specify individual usages of the contents solely in the useconditions of the corresponding license. In such cases, the useconditions are attached to individual contents for additional managementpurposes apart from the licenses.

As shown in FIG. 32, the mark may illustratively have a user ID (leafID), an ownership flag, a use start time, and a copy count describedtherein.

The mark is also supplemented with a digital signature based on the leafID, ownership flag, use start time, copy count and the like constitutinga message.

The ownership flag is added if the license for grating a limited-timeuse of the content is replaced by an outright purchase of the license(i.e., for permanent usage) The use start time is described if thecontent has started to be used within a specific time period.Illustratively, if the time period in which to download the content islimited, the use start time described here indicates the actual date andtime at which the content is downloaded within that period. This is tocertify that the content is used legitimately within the designatedperiod.

The copy count is a log describing the number of times the content inquestion has been copied so far.

Described below with reference to the flowchart of FIG. 33 is how a markis added to a content when the user purchases the license for thatcontent.

In step S221, the CPU 21 first gains access to the license server 4 overthe Internet 2 in response to a command entered by the user into theinput unit 26.

In step S222, the CPU 21 acquires the command input from the userthrough the input unit 26. In accordance with the command, the CPU 21requests an outright purchase of the license from the license server 4.

Upon receipt of the request, the license server 4 proposes a price forthe license, as will be described later with reference to the flowchartof FIG. 34 (in step S242 of FIG. 34). In step S223, the CPU 21 of theclient 1 receives the proposed price from the license server 4 andcauses the output unit 27 to display the price.

Upon viewing the display, the user decides whether or not to accept theproposed price. The user enters the result of his or her decision intothe input unit 26.

In step S224, the CPU 21 receives the user's input through the inputunit 26 and judges whether or not the user has accepted the proposedprice. If the proposed price is judged accepted, the CPU 21 goes to stepS225 and reports the acceptance to the license server 4.

Given the report of the acceptance, the license server 4 returns a markthat has an ownership flag, i.e., information denoting the outrightpurchase of the license at the proposed price, described therein (instep S244 of FIG. 34). In step S226, the CPU 21 of the client 1 receivesthe mark from the license server 4. In step S227, the CPU 21 embeds thereceived mark into the content. This causes the mark including theownership flag of FIG. 32 to be recorded as a mark of content relativeto the purchased license in correspondence with the content. With themessage thus renewed, the CPU 21 also renews the digital signature (FIG.26) and writes the renewed signature to the storage medium.

If in step S224 the price proposed by the license server 4 is not judgedaccepted, step S228 is reached. In step S228, the CPU 21 reportsrejection of the proposed price to the license server 4.

In conjunction with the above-described process of the client 1, thelicense server 4 carries out the steps in the flowchart of FIG. 34.

In step S241, the CPU 21 of the license server 4 first receives alicense purchase request from the client 1 (in step S222 of FIG. 33)Upon receipt of the request, the CPU 21 goes to step S242 to retrievefrom the storage unit 28 the price for the outright purchase of thelicense in question, and transmits the price to the client 1.

As described above, the client 1 reports either the acceptance or therejection of the proposed price.

In step S243, the CPU 21 of the license server 4 judges whether or notthe report of the acceptance is received from the client 1. If theacceptance report is judged received, then step S244 is reached. In stepS244, the CPU 21 of the license server 4 generates a mark that containsa message specifying the purchase of the license in question, affixes adigital signature to the mark using its own private key, and transmitsthe mark to the client 1. The mark thus transmitted is written to theapplicable content in the storage unit 28 of the client 1 as describedabove (in step S227 of FIG. 33).

If in step S243 the acceptance report is not judged received from theclient 1, then step S244 is skipped. In this case, the purchase of thelicense is not accomplished, so that the mark will not be transmitted.

FIG. 35 shows a typical structure of a mark transmitted from the licenseserver 4 to the client 1. In this example, the mark is made up of theuser's leaf ID and his or her ownership flag (Own) and of a digitalsignature Sigs(LeafID, Own) generated using a private key S of thelicense server 4 on the basis of the leaf ID and ownership flag.

The mark is valid only for a specific content of a particular user. Ifthe content in question is copied, the mark accompanying the copiedcontent is invalidated.

As described, each content and its license are handled independently ofone another, and the use conditions are associated with each license.This scheme makes it possible to offer diverse services reflecting thedifferent use status of individual contents.

Described below is what is known as grouping. Grouping involves puttingtogether a plurality of devices or storage media to form a group withinwhich a content may be exchanged freely. Grouping usually applies todevices or storage media owned by an individual. Whereas the devices orstorage media forming a single group were conventionally assigned agroup key for control purposes, the target devices or storage media tobe grouped may be associated with a single license for easier groupingcontrol according to the invention.

It is also possible to register beforehand each of the devices forming agiven group for the same control purpose. Typical grouping with devicesregistered in advance will now be described.

In this example, the user needs to register beforehand with the serverthe certificates of the devices to be grouped. The certificates areregistered in the steps of the flowcharts in FIGS. 36 and 37.

Referring first to FIG. 36, the client (one of the devices to begrouped) has its certificate registered as follows: in step S261, theCPU 21 of the client 1 which is subjected to grouping prepares its owncertificate containing its public key.

In step S262, the CPU 21 gains access to the content server 3 based onthe user's input through the input unit 26. In step S263, thecertificate prepared in step S261 is transmitted to the content server3.

Alternatively, the certificate received from the license server 4 may beused unmodified for the registration.

The steps above are carried out by all devices that constitute the groupin question.

Described below with reference to the flowchart of FIG. 37 is how thecontent server 3 performs a certificate registering process inconjunction with the registering process carried out by the client 1 asshown in FIG. 36. In step S271, the CPU 21 of the content server 3receives the certificate from the client 1. In step S272, the CPU 21stores the received certificate into the storage unit 28.

The steps above are carried out regarding each of the devicesconstituting the group in question. As a result, the storage unit 28 ofthe content server 3 has the certificates of the devices registered inunits of groups, as illustrated in FIG. 38.

In the example of FIG. 38, a group 1 is matched with certificates C11through C14 being registered. The certificates C11 through C14 containcorresponding public keys K_(P11) through K_(P14) respectively.

Likewise, certificates C21 through C23 are registered in associationwith a group 2. The certificates C21 through C23 include correspondingpublic keys KP₂₁ through KP₂₃ respectively.

In the manner described, the devices constituting each of the groupsabove have their certificates registered in advance. It might happenthat a user possessing a group of devices requests the content server 3to provide a content to the grouped devices. In that case, the contentserver 3 carries out the steps in the flowchart of FIG. 39.

In step S281, the CPU 21 of the content server 3 first authenticates thecertificates belonging to the group in question from among thecertificates held in the storage unit 28.

The authenticating process of step S281 is carried out as describedabove with reference to FIGS. 30 and 31, by tracing EKBs using tagsbased on the leaf IDs included in the certificates of the devicesinvolved. The EKBs are also distributed to the content server 3 from thelicense server 4. The authenticating process rules out any certificatethat has been revoked.

In step S282, the CPU 21 of the content server 3 selects thecertificates found valid following the authenticating process of stepS281. In step S283, the CPU 21 encrypts the content key using thosecertificates of the devices which were selected in step S282. In stepS284, the CPU 21 transmits to the grouped devices the content togetherwith the content key encrypted in step S283. Suppose now that in thegroup 1 of FIG. 38, the certificate C14 is found revoked. In such acase, the process of step S283 generates encrypted data shown in FIG.40.

In the example of FIG. 40, the content key Kc is shown encrypted usingthe public key K_(P11) of the certificate C11, public key K_(P12) of thecertificate C12, or public key K_(P13) of the certificate C13.

In conjunction with the process of FIG. 39 carried out by the contentserver 3, each of the grouped devices (i.e., clients) receiving thecontent performs the steps shown in the flowchart of FIG. 41.

In step. S291, the CPU 21 of the client 1 receives the content togetherwith the content key following its transmission from the content server3 in step S284 of FIG. 39. The content has been encrypted by use of thecontent key Kc which in turn has been encrypted by the public keyretained by each of the devices involved (FIG. 40).

In step S292, the CPU 21 using its own private key decrypts and acquiresthe content key addressed to the client, the self-addressed content keyhaving been received in step S291. The acquired content key is then usedto decrypt the content.

Illustratively, the device corresponding to the certificate C11 shown inFIG. 40 decrypts and acquires the content key Kc using its private keypaired with the public key K_(P11). The content key Kc is then utilizedin decrypting the content.

The above-described steps are also carried out by the devicescorresponding to the certificates C12 and C13. The device correspondingto the revoked certificate C14 does not receive along with the content acontent key Kc that would have been encrypted by use of the public keyspecific to the device in question. That means the device is incapableof acquiring the content using the content key Kc.

In the foregoing description, devices are shown grouped with respect tothe content key (i.e., content). Alternatively, devices may be groupedwith regard to a license key (i.e., license).

In the manner described, multiple devices may be grouped for controlpurposes without recourse to a special group key or to an ICV (integritycheck value), to be described later. The grouping procedure above isbest suited for grouping a small number of devices.

According to this invention, it is also possible to checked out, checkin, move or copy licenses. These processes are carried out under rulesstipulated by SDMI.

How a license is checked out by a client will now be described byreferring to the flowcharts of FIGS. 42 and 43.

Described first are the steps in which the client checks out a licenseto another client, as shown in FIG. 42. In step S301, the CPU 21 of theclient 1 reads a check-out count N1 of the license to be checked out.The check-out count is retrieved from the use conditions such as thoseshown in FIG. 8.

In step S302, the CPU 21 reads a maximum check-out count N2 of thelicense to be checked out. The maximum check-out count is also retrievedfrom the use conditions of the license.

In step S303, the CPU 21 compares the check-out count N1 retrieved instep S301 with the maximum check-out count N2 read in step S302. A checkis made to see if the check-out count N1 is smaller than the maximumcheck-out count N2.

If the check-out count N1 is judged smaller than the maximum check-outcount N2, step S304 is reached. In step S304, the CPU 21 acquires theleaf key of the other client (i.e., client of the check-out destination)and writes the acquired leaf key to a check-out list in the storage unit28 in correspondence with the ID of the license to be checked out.

In step S305, the CPU 21 increments by 1 the check-out count N1 of thelicense, the count having been retrieved in step S301. In step S306, theCPU 21 computes an ICV based on the message of the license. The ICV willbe described later with reference to FIGS. 47 through 51. The ICV schemeis designed to prevent the tampering of the licenses.

In step S307, the CPU 21 encrypts the license in question as well as theICV computed in step S306 using the public key of this client, andoutputs what is encrypted together with an EKB and a certificate to theother client for copying. In step S308, the CPU 21 writes the ICVcomputed in step S306 to a check list in the storage unit 28 incorrespondence with the leaf key of the other client and the license ID.

If in step S303 the check-out count N1 is not judged smaller than (e.g.,found equal to) the maximum check-out count N2, that means the maximumpermissible check-out count has been exhausted so that the license canno longer be checked out. In that case, the CPU 21 goes to step S309 forerror handling. The check-out process will be terminated unaccomplished.

Described below with reference to the flowchart of FIG. 43 is how aclient has a license checked out from another client. This process takesplace in conjunction with the check-out process of FIG. 42.

In step S321, the CPU 21 of the client 1 (of the check-out destination)transmits the leaf key of this client to another client (i.e., thelicense check-out source client). The leaf key is stored by the otherclient in correspondence with the license ID (in step S304).

In step S322, the CPU 21 receives from the other client 1 the encryptedlicense and ICV together with the EKB and certificate. The license, ICV,EKB, and certificate were transmitted earlier by the other client instep S307 of FIG. 42.

In step S323, the CPU 21 stores into the storage unit 28 the license,ICV, EKB, and certificate received in step S322.

The client 1 has the license checked out thereto from the other clientin the manner described-above. Thereafter, the client 1 reproduces thecontent corresponding to the checked-out license by carrying out thesteps in the flowchart of FIG. 44.

In step S341, the CPU 21 of the client 1 computes the ICV of the contentdesignated to be reproduced by the user through the input unit 26. Instep S342, the CPU 21 decrypts the ICV in the storage unit 28 based onthe public key included in the certificate.

In step S343, the CPU 21 judges whether or not the ICV computed in stepS341 matches the ICV that was retrieved and decrypted in step S341. Ifthe two values match, it means the license has not been tampered with.In that case, the CPU 21 goes to step S344 to reproduce the applicablecontent.

If in step S343 the two ICVs fail to match, that means the license mayhave been tampered with. In such a case, the CPU 21 goes to step S345for error handling. Here, the content cannot be reproduced by use of thelicense in question.

Described below with reference to the flowchart of FIG. 45 is how aclient has a previously checked-out license checked in from anotherclient.

In step S361, the CPU 21 first acquires the leaf key of the other client(i.e., the client about to check in the license) and the ID of thelicense to be checked in. In step S362, the CPU 21 judges whether or notthe target license whose ID was acquired in step S361 is a licensepreviously checked out from this client to the other client. Thejudgment is made based on the ICV, leaf key and license ID stored instep S308 of FIG. 42. More specifically, a check is made to see whetheror not the leaf key, license ID and ICV acquired in step S361 are heldin the check-out list. If the leaf key, license ID and ICV are judgedretained in the check-out list, that means the license in question hasindeed been checked out by this client to the other client.

If the result of the check in step S362 is affirmative, then the CPU 21goes to step S363 requesting the other client to delete the license, EKBand certificate involved. Given the request, the other client deletesthe license, EKB and certificate as will be described later (in stepS383 of FIG. 46).

In step S364, the CPU 21 decrements by 1 the check-out count N1 of thelicense in question. This is done to reflect the fact that a previouslychecked-out license is now returned (i.e., checked in).

In step S365, the CPU 21 determines whether or not this client has anyother license still checked out to the other client. If there is no suchlicense, step S366 is reached in which the CPU 21 deletes from thecheck-out list the record of the other client as a possible client forsubsequent check-in. If in step S365 any other license is judged stillchecked out to the other client, the other client may subsequentlyrequest another check-in session and thus step S366 is skipped.

If in step S362 the license in question is not judged to be onepreviously checked out to the other client, then the CPU 21 goes to stepS367 for error handling. In this case, the license in question is notsubject to control by this client and the check-in process will not takeplace.

If the user has illegally copied the license, the stored ICV becomesdifferent from the ICV computed on the basis of the license acquired instep S361. In that case, the check-in process will end unaccomplished.

FIG. 46 shows steps performed by a client having its license checked into another client. This process takes place in conjunction with thelicense check-in process shown in the flowchart of FIG. 45.

In step S381, the CPU 21 of the client 1 transmits to another client(i.e., client 1 carrying out the steps in the flowchart of FIG. 45) theleaf key of this client 1 and the ID of the license to be checked in. Asdescribed above, the other client acquired earlier the leaf key andlicense ID in step S361 and authenticated the license to be checked inbased on the acquired leaf key and license ID in step S362.

In step S382, the CPU 21 of this client 1 judges whether or not theother client has requested deletion of the license. That is, if thelicense is a legitimate license that can be checked in, the other clientrequests deletion of the license, EKB and certificate involved in stepS363 as described above. Upon receipt of that request, the CPU 21reaches step 5383 to delete the license, EKB and certificate. Followingstep S383, the other client can no longer make use of the license inquestion. The check-out count N1 of the license is then decremented by 1in step S364 and the check-in process is accomplished.

If in step S382 the other client is not judged to request the deletionof the license, then the CPU 21 goes to step S384 for error handling.The check-in process remains unaccomplished due to a mismatch of theICVs involved.

In the same manner in which the check-in and check-out processes arecarried out as described above, licenses can also be copied or movedfrom one client to another.

What follows is a description of how an integrity check value (ICV) isgenerated for each license, how the ICV is brought into correspondencewith the license, and how the ICV is computed to determine whether ornot the license in question has been tampered with. The same processapplies to prevention of tampering with regard to both licenses andcontents.

The ICV (integrity check value) for a given license is computedillustratively by having a hash function applied to that license asICV=hash(Kicv, L1, L2, . . . )where Kicv stands for an ICV generation key, and L1, L2, . . . denotelicense information. A message authentication code (MAC) for use in ICVgeneration constitutes an important element of the license information.

FIG. 47 is an explanatory view showing how a message authentication code(MAC) is generated using a DES (Data Encryption Standard) arrangement.As shown in FIG. 47, a message to be encrypted by DES is divided intounits of eight bytes (the divided units of the message are calleddivided messages M1, M2, . . . , MN hereunder). First, an initial value(IV) and the divided message M1 are exclusively ORed by an arithmeticunit 24-1A outputting a resulting value of Ii. The value 11 is input toa DES encryption unit 24-1B for an encrypting process using a key K1,the unit 24-1B outputting a resulting value of E1. The value E1 anddivided message M2 are exclusively ORed by an arithmetic unit 24-2Awhich outputs a resulting value of I2. The value I2 is input to a DESencryption unit 24-2B for an encrypting process using the key K1, theunit 24-2B outputting a resulting value of E2. These steps are repeatedto cover all divided messages. A value EN ultimately resulting from aDES encryption unit 24-NB in the most downstream stage constitutes amessage authentication code (MAC).

A hash function is applied to the MAC thus acquired and to the ICVgeneration key for the license, whereby an integrity check value (ICV)of the license is generated. Illustratively, if the ICV created upongeneration of the license is judged to be the same as the ICV producedanew based on the license, it guarantees that the license has not beentampered with. If the two ICVs are found to be different uponcomparison, that means the license has been tampered with.

Described below is how the ICV generation key Kicv of a given license istypically delivered to devices using the above-described enabling keyblock (EKB). In this case, encrypted message data in the EKB are used asthe ICV generation key for the license in question.

FIGS. 48 and 49 show examples in which a license common to a pluralityof devices is sent to them with an enabling key block (EKB) used todeliver the ICV generation key Kicv for verifying the integrity of thelicense in question. The example of FIG. 48 involves delivering an ICVgeneration key Kicv decryptable by devices 0, 1, 2 and 3, while theexample of FIG. 49 involves delivering an ICV generation key Kicvdecryptable solely by devices 0, 1 and 2 with the device 3 revoked.

In the example of FIG. 48, a renewed node key K(t)00 is used to encryptthe ICV generation key Kicv, giving data Enc(K(t)00, Kicv). The dataEnc(K(t)00, Kicv) are delivered along with the EKB from which therenewed node key K(t)00 may be decrypted by each of the devices 0, 1, 2and 3 using their respective node keys and leaf keys. As shown on theright-hand side of FIG. 48, each device first decrypts the EKB toacquire the renewed node key K(t)00, and decrypts the encrypted ICVgeneration key Enc(K(t)00, Kicv) using the acquired node key K(t)00 inorder to obtain the ICV generation key Kicv.

The other devices 4, 5, 6, 7, etc., even when they receive the sameenabling key block (EKB), cannot acquire the renewed node key K(t)00 bydecrypting the received EKB using their own node keys and leaf keys.Thus only the legitimate devices alone can receive the delivered ICVgeneration key.

In the example of FIG. 49, it is assumed that the device 3 in the groupenclosed by broken line in FIG. 12 is revoked because of a leaked keyand that the enabling key block (EKB) decryptable only by the devices 0,1 and 2 is generated and delivered to them. The EKB and the ICVgeneration key Kicv in FIG. 49 are encrypted by the node key K(t)00 toproduce encrypted data Enc(K(t)00, Kicv) for delivery to the devicesinvolved.

Shown on the right-hand side of FIG. 49 are steps for decrypting thedelivered EKB and encrypted data. The devices 0, 1 and 2 first acquirethe renewed node key K(t)00 by decrypting the received EKB using theirown leaf keys or node keys. The renewed node key K(t)00 thus acquired isthen used in a decrypting process to obtain the ICV generation key Kicv.

The devices 4, 5, 6, etc., in other groups shown in FIG. 12 may receivethe same data (i.e., EKB) but are incapable of acquiring the renewednode key K(t)00 from the received data using their own leaf keys or nodekeys. Similarly, the revoked device 3 cannot obtain the renewed node keyK(t) 00 using its own leaf key or node key. Only the devices withlegitimate rights are capable of decrypting the ICV generation value fortheir use.

Where the ICV generation key is delivered by use of the EKB as describedabove, it is possible to implement a scheme whereby the ICV generationkey is delivered in a way securely decryptable only by those entitled toreceive the key with a minimum of data amount involved.

The use of the integrity check value (ICV) for licenses makes itpossible to eliminate illegal copy of EKBs and encrypted licenses.Illustratively, as shown in FIG. 50A, suppose that licenses L1 and L2are stored on a storage medium 1 together with EKBs for allowing thelicenses to be acquired and that what is stored on the storage medium 1is copied entirely to a storage medium 2. In that case, with the EKBsand licenses copied onto the storage medium 2, the copied licenses canbe used by any device capable of decrypting the EKBs.

In the example of FIG. 50B, the licenses held legitimately on a givenstorage medium are furnished with a corresponding integrity check valueICV(L1, L2) The value ICV(L1, L2) denotes an ICV given asICV=hash(Kicv, L1, L2)which is an integrity check value computed by having a hash functionapplied to the licenses L1 and L2. In the example of FIG. 50B, thestorage medium 1 legitimately contains the licenses L1 and L2 togetherwith the integrity check value TCV(L1, L2) generated based on the twolicenses. The storage medium 2 legitimately contains the license L1along with an integrity check value ICV(L1) generated based on thelicense Li.

In the case of FIG. 50B, suppose that the EKB and the license 2 held onthe storage medium 1 are copied to the storage medium 2 and that alicense check value is generated anew for the storage medium 2. In thatcase, the integrity check value ICV(L1, L2) is generated which differsfrom Kicv(L1) retained on the storage medium 2. This reveals tamperingwith or illegal copy of the license that has been written to the storagemedium. A device about to reproduce data from the storage medium carriesout an ICV check before a data-reproducing step to determine whether ornot there is a match between the generated ICV and the stored ICV. Incase of a mismatch, the device will not reproduce data from the storagemedium. This prevents reproduction of any illegally copied license.

In order to enhance security further, it is possible to generate theintegrity check value (ICV) for each license on the basis of dataincluding a renewal counter. More specifically, the ICV is computed asICV=hash(Kicv, counter+1, L1, L2, . . . )where the counter (counter+1) is established as a value that isincremented by 1 every time the ICV is renewed. The counter value needsto be stored in a secure memory.

Where the ICV for a license cannot be held on the same storage medium asthe license in question, that ICV may be held on a storage mediumseparate from that of the license.

Illustratively, if a license is placed onto a read-only medium, an MO,or like storage medium that is not copy-protected, then putting thecorresponding ICV on the same medium may prompt an unscrupulous userillegally to renew the ICV compromising its integrity. Such aneventuality is circumvented by keeping the ICVs on a secure storagemedium in the host machine so that they are retrieved as needed forlicense copy control (e.g., check-in, check-out, move). This schemeprovides securer ICV control measures and more elaborate licensetampering checks.

The scheme above is typically implemented as shown in FIG. 51. In theexample of FIG. 51, licenses 1, 2 and 3 are held on a storage medium2201 such as a read-only medium, an MO or other storage medium that isnot copy-protected. The ICV regarding these licenses is retained on asecure storage medium 2202 in the host machine that cannot be accessedfreely by users. This arrangement prevents dishonest users fromillegally renewing the integrity check value (ICV). Each device loadedwith the storage medium 2201 requests the host machine such a PC or aserver to perform ICV checks to determine whether or not datareproduction from the loaded storage medium is permitted. Thiseffectively prevents illegal copying of or tampering with any license.

The clients to which this invention applies include not only so-calledpersonal computers but also PDAs (personal digital assistants), mobiletelephones and game consoles.

The series of steps described above may be executed either by hardwareor by software. For software-based processing to take place, programsconstituting the software may be either incorporated beforehand indedicated hardware of a computer or installed upon use over a network orfrom a suitable program storage medium into a general-purpose personalcomputer or like equipment capable of executing diverse functions.

As shown in FIG. 2, the program storage medium is offered to users apartfrom computers not only as a package medium constituted by the magneticdisc 41 (including floppy discs), optical disc 42 (including CD-ROM(compact disc-read only memory) and DVD (digital versatile disc)),magneto-optical disc 43 (including MD (Mini-disc)), or semiconductormemory 44, each containing the necessary programs; but also in the formof the ROM 22 or the hard disc in the storage unit 28 which contains theprograms and which are incorporated in the computers before beingoffered to users.

In this specification, the steps which are stored on the program storagemedium and which describe the programs to be executed represent not onlythe processes that are carried out in the depicted sequence (i.e., on atime series basis) but also processes that are conducted parallelly orindividually.

Any programs implementing security-related processes should preferablybe encrypted to guard against analysis for tampering. Illustratively,the programs for carrying out cryptographic processes should bestructured as tamper-resistant modules.

Information placed in the header of a content to identify the licensefor using that content is not limited to the license ID for uniquelyidentifying the license in question. In the above-described embodiments,the license ID serves as information which specifies the licensegranting the use of a particular content; as information whichidentifies the content whose use is granted by a specific license; andas information which is requested by a license request from the client 1for identification of a given license. Alternatively, each content mayinclude a list of information about various attributes of the content inquestion, and each license may comprise a conditional expression of thecontent whose use is granted by the license in question. In this case,the attribute information attached to each content constitutesinformation for identifying the license for granting the use of thecontent in question, and the conditional expression included in eachlicense serves as information for specifying the content whose use isgranted by the license in question; the license ID serves as informationfor uniquely identifying each license. These arrangements make itpossible to assign a plurality of licenses to a single content, therebyproviding a flexible license issuing scheme.

The content data are not limited to music data. Contents may beconstituted illustratively by image data, moving image data, text data,animation data, software programs, or a combination of any of them.

In this specification, the term “system” refers to an entireconfiguration made up of a plurality of component devices.

INDUSTRIAL APPLICABILITY

In the information processing apparatus according to this invention, adifferent device node key is distributed for each client. Such structureleads the appropriate registration processing for use of contentdistributed by the content distribution system.

1. An information processing apparatus for providing a secondinformation processing apparatus with a key to decrypt an encryptedcontent when said information processing apparatus is accessed by saidsecond information processing apparatus, said information processingapparatus comprising: receiving means adapted to receive a key requestand a license request for using content from said second informationprocessing apparatus; key generating means adapted to generate a devicenode key by assigning said second information processing apparatus to aleaf of a key-managed hierarchical tree structure according to thereceived key request; license generating means adapted to generate alicense including leaf identification information and content usecondition according to the received license request; and transmittingmeans adapted to transmit to said second information processingapparatus said device node key generated by said key generating meansand the leaf identification information for identifying the leafassigned to said second information processing apparatus, and totransmit said license to said second information processing apparatus;wherein the device node key is provided to said second informationprocessing apparatus to decrypt an encrypted key set provided with theencrypted content data.
 2. The information processing apparatusaccording to claim 1, wherein said transmitting means is further adaptedto transmit a private key assigned to said second information processingapparatus according to said key request.
 3. The information processingapparatus according to claim 1, wherein said second informationprocessing apparatus is adapted to determine whether or not the licensehas expired, and to decrypt the content by said device node key if thelicense has not expired.
 4. An information processing method for usewith an information processing apparatus for providing a secondinformation processing apparatus with a key to decrypt an encryptedcontent when said information processing apparatus is accessed by saidsecond information processing apparatus, said information processingmethod comprising: receiving a key request and a license request forusing content from said second information processing apparatus;generating a device node key by assigning said second informationprocessing apparatus to a leaf of a key-managed hierarchical treestructure according to the received key request; generating a licenseincluding leaf identification information and content use conditionaccording to the received license request; and transmitting to saidsecond information processing apparatus the generated device node keyand the leaf identification information for identifying the leafassigned to said second information processing apparatus, andtransmitting said license to said second information processingapparatus; wherein the device node key is provided to said secondinformation processing apparatus to decrypt an encrypted key setprovided with the encrypted content data.
 5. A storage medium whichstores a computer-readable program for use with an informationprocessing apparatus for providing a second information processingapparatus with a key to decrypt an encrypted content when saidinformation processing apparatus is accessed by said second informationprocessing apparatus, the program comprising: receiving a key requestand a license request for using content from said second informationprocessing apparatus; generating a device node key by assigning saidsecond information processing apparatus to a leaf of a key-managedhierarchical tree structure according to the received key request;generating a license including leaf identification information andcontent use condition according to the received license request; andtransmitting to said second information processing apparatus thegenerated device node key and the leaf identification information foridentifying the leaf assigned to said second information processingapparatus, and transmitting said license to said second informationprocessing apparatus; wherein the device node key is provided to saidsecond information processing apparatus to decrypt an encrypted key setprovided with the encrypted content data.
 6. A program executable by acomputer for controlling an information processing apparatus forproviding a second information processing apparatus with a key todecrypt an encrypted content when said information processing apparatusis accessed by said second information processing apparatus, saidprogram causing said computer to carry out: receiving a key request anda license request for using content from said second informationprocessing apparatus; generating a device node key by assigning saidsecond information processing apparatus to a leaf of a key-managedhierarchical tree structure according to the received key request;generating a license including leaf identification information andcontent use condition according to the received license request; andtransmitting to said second information processing apparatus thegenerated device node key and the leaf identification information foridentifying the leaf assigned to said second information processingapparatus, and transmitting said license to said second informationprocessing apparatus; wherein the device node key is provided to saidsecond information processing apparatus to decrypt an encrypted key setprovided with the encrypted content data.
 7. The information processingapparatus according to claim 1, wherein said transmitting means isfurther adapted to transmit a user request according to the received keyrequest and said receiving means is further adapted to receive userinformation about a user of said second information processingapparatus.
 8. The information processing apparatus according to claim 7,further comprising store means adapted to store the user informationcorresponding to the device node key, and to store the licensecorresponding to the user information according to the licensetransmitted to said second information processing apparatus.